Typical computer systems, especially computer systems using graphical user interface (GUI) systems such as Microsoft WINDOWS, are optimized for accepting user input from one or more discrete input devices such as a keyboard and for entering text, and a pointing device such as a mouse with one or more buttons for driving the user interface. Virtually all software applications designed to run on Microsoft WINDOWS are optimized to accept user input in the same manner. For instance, many applications make extensive use of the right mouse button (a “right click”) to display context-sensitive command menus. The user may generate other gestures using the mouse such as by clicking the left button of the mouse (a “left click”), or by clicking the left or right button of the mouse and moving the mouse while the button is depressed (either a “left click drag” or a “right click drag”). See, for example, the right-click-drag mouse commands in Opera 6.0 by Opera Software.
In some environments, a mouse is not usable or desirable. For example, in a digitizer tablet environment, the primary input device may be a stylus. While a stylus attempts to provide pad and paper-like feel to a computing environment, current systems are limited. For example, the use of a stylus in a graphical user interface is limited to tapping on various items for selection. See, for example, the Palm-series of products using the Palm OS 3.x and 4.x operating systems. Also, in these systems, the interaction methodology is cumbersome in that the text entry and commands are input on a dedicated portion of the digitizer, far from the insertion point or selected word or words). Further, in stylus-based input environments, a user is continually forced to select tools or operations from a remote tool bar, generally on a top or bottom of a screen. While a user can type in letters or a digitizer can recognize handwriting, these operations require selecting a keyboard input mode and writing in a predefined portion of the digitizer, respectively. In short, requiring a user to tell the computer, for every new input, what a user wants to do makes stylus-based computing difficult for the average user.
Some operations create new text (for example, writing, typing, pasting text and the like). Other operations modify the text (highlighting, inking, erasing, cutting and moving existing text). A problem with performing the latter modifying operations is that these latter operations are not generally the primary mode of operating for most users. In other words, while a user may modify text, this operation will be secondary to more primary operations of creating new text. Accordingly, the user will eventually need to transition from the modifying text (or other content) operation to the creating text environment. Conventional transitions include toggling a button on a tool bar. Buttons may include an erase button, a highlight button and the like. Toggle buttons, while making it clear for a user on how to select the operating mode and the state of the mode (by whether the toggle buttons are depressed or not), can be cumbersome to use when alternating between various modes in that the user is continuously moving from generally a central portion of a display screen to a remote tool bar (housing the toggle button) juxtaposed to an end of the screen then back again. This repetitive motion and the attention one needs to employ to switch from the auxiliary mode or modes back to the primary mode of operation distracts the user's attention from actively reading or writing to the mundane task of switching between modes.
Previous pen-based computing systems have attempted to address the above problems by permitting a pen action to be interpreted as a command. See, for example, Penpoint by the Go Corporation. However, Penpoint primarily enabled pen-based commands on text. For handwritten input, Penpoint only permitted the immediate deletion of the previous input by a specified pen movement (here, a right, left, right co-linear movement of the pen tip, also referred to as a flat “z”). Penpoint did not provide the ability to randomly edit handwritten ink anywhere on a page. For pen-based input systems to become part of the mainstream computing environment, support for the freedom of editing handwritten text anywhere on a page needs to occur.
Finally, handwritten ink is not generally compatible with non-ink applications. For example, using an application that requires text input forces users to convert ink to text. In the Palm OS, one needs to place an insertion point, move to a dedicated text input portion at the bottom of the screen, enter the text in the dedicated text input portion, and then return back to the insertion point. These actions quickly become cumbersome and force users away from using legacy applications with a stylus-based input system.